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Abstract.  The  Tor  network  relies  on  volunteer  relay  operators  for  re¬ 
lay  bandwidth,  which  may  limit  its  growth  and  scaling  potential.  We 
propose  an  incentive  scheme  for  Tor  relying  on  two  novel  concepts.  We 
introduce  TorCoin,  an  “altcoin”  that  uses  the  Bitcoin  protocol  to  re¬ 
ward  relays  for  contributing  bandwidth.  Relays  “mine”  TorCoins,  then 
sell  them  for  cash  on  any  existing  altcoin  exchange.  To  verify  that  a  given 
TorCoin  represents  actual  bandwidth  transferred,  we  introduce  TorPath, 
a  decentralized  protocol  for  forming  Tor  circuits  such  that  each  circuit  is 
privately-addressable  but  publicly  verifiable.  Each  circuit’s  participants 
may  then  collectively  mine  a  limited  number  of  TorCoins,  in  proportion 
to  the  end-to-end  transmission  goodput  they  measure  on  that  circuit. 


1  Introduction 

The  Tor  network  suffers  from  slow  speeds,  due  to  a  shortage  of  relay  nodes 
from  volunteers.  This  is  a  well  studied  problem,  but  despite  many  attempts,  there 
is  not  yet  a  widely-adopted  mechanism  for  compensating  relay  operators  while 
retaining  anonymity  of  clients  [1-7].  This  paper  outlines  one  possible  solution, 
embodying  two  complementary  novel  ideas: 

1.  TorCoin  is  an  alternative  cryptocurrency,  or  altcoin,  based  on  the  Bitcoin 
protocol  [8] .  Unlike  Bitcoin,  its  proof-of-work  scheme  is  based  on  bandwidth 
rather  than  computation.  To  “mine”  a  TorCoin,  a  relay  transfers  bandwidth 
over  the  Tor  network.  Since  relays  can  sell  TorCoin  on  any  existing  altcoin 
exchange,  TorCoin  effectively  compensates  them  for  contributing  bandwidth 
to  the  network,  and  does  not  require  clients  to  pay  for  access  to  it. 

2.  TorPath  is  a  secure  bandwidth  measurement  mechanism  that  utilizes  decen¬ 
tralized  groups  of  “Assignment  Servers,”  extending  Tor’s  existing  “Directory 
Servers,”  to  assign  each  client  a  Tor  circuit  that  is  publicly  verifiable,  but  pri¬ 
vately  addressable.  This  mechanism  allows  TorPath  to  “sign”  newly-minted 
TorCoins,  so  that  anyone  can  verify  a  TorCoin  by  checking  the  blockchain. 


Report  Documentation  Page 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  the  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources,  gathering  and 
maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information  Send  comments  regarding  this  burden  estimate  or  any  other  aspect  of  this  collection  of  information, 
including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson  Davis  Highway,  Suite  1204,  Arlington 

VA  22202-4302  Respondents  should  be  aware  that  notwithstanding  any  other  provision  of  law,  no  person  shall  be  subject  to  a  penalty  for  failing  to  comply  with  a  collection  of  information  if  it 
does  not  display  a  currently  valid  0MB  control  number 

1.  REPORT  DATE 

18  JUL  2014 

2.  REPORT  TYPE 

3.  DATES  COVERED 

00-00-2014  to  00-00-2014 

4.  TITLE  AND  SUBTITLE 

A  TorPath  to  TorCoin:  Proof-of-Bandwidth  Altcoins  for  Compensating 
Relays 

5a.  CONTRACT  NUMBER 

5b.  GRANT  NUMBER 

5c.  PROGRAM  ELEMENT  NUMBER 

6.  AUTHOR(S) 

5d.  PROJECT  NUMBER 

5e.  TASK  NUMBER 

5f.  WORK  UNIT  NUMBER 

7.  PEREORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Naval  Research  Laboratory  ,Washington,DC,20375 

8.  PERFORMING  ORGANIZATION 

REPORT  NUMBER 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

10.  SPONSOR/MONITOR’S  ACRONYM(S) 

II.  SPONSOR/MONITOR’S  REPORT 
NUMBER(S) 

12.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Approved  for  public  release;  distribution  unlimited 

13.  SUPPLEMENTARY  NOTES 

7th  Workshop  on  Hot  Topics  in  Privacy  Enhancing  Technologies  (HotPETs),  18  Jul  2014,  Amsterdam, 
Netherlands. 


14.  ABSTRACT 

The  Tor  network  relies  on  volunteer  relay  operators  for  re-  lay  bandwidth,  which  may  limit  its  growth  and 
scaling  potential.  We  propose  an  incentive  scheme  for  Tor  relying  on  two  novel  concepts.  We  introduce 
TorCoin,  an  altcoin"  that  uses  the  Bitcoin  protocol  to  re-  ward  relays  for  contributing  bandwidth.  Relays 
mine"  TorCoins,  then  sell  them  for  cash  on  any  existing  altcoin  exchange.  To  verify  that  a  given  TorCoin 
represents  actual  bandwidth  transferred,  we  introduce  TorPath  a  decentralized  protocol  for  forming  Tor 
circuits  such  that  each  circuit  is  privately-addressable  but  publicly  veri  able.  Each  circuit’s  participants 
may  then  collectively  mine  a  limited  number  of  TorCoins,  in  proportion  to  the  end-to-end  transmission 
goodput  they  measure  on  that  circuit. 


15.  SUBJECT  TERMS 


16.  SECURITY  CLASSIFICATION  OF: 

17.  LIMITATION  OF 
ABSTRACT 

18.  NUMBER 

OE  PAGES 

1 9a.  NAME  OE 
RESPONSIBLE  PERSON 

a  REPORT 

unclassified 

b  ABSTRACT 

unclassified 

c  THIS  PAGE 

unclassified 

Same  as 
Report  (SAR) 

13 

Standard  Form  298  (Rev.  8-98) 

Prescribed  by  ANSI  Std  Z39-18 


2  Motivation  and  Related  Work 


Solving  the  problem  of  compensating  Tor  relays  is  attractive  in  that  it  might 
immediately  improve  the  scalability  of  the  Tor  network.  Prior  research  has  not 
arrived  at  a  fully  satisfactory  design  for  such  an  incentive  scheme,  however.  We 
now  outline  what  we  believe  to  be  the  key  requirements  for  such  a  scheme,  while 
noting  that  more  extensive  discussion  of  these  requirements  and  the  architectural 
tradeoffs  they  entail  is  available  elsewhere  [9]. 

2.1  Requirements  of  an  Incentive  System 

An  incentive  system  must  retain  anonymity  but  verifiably  measure  bandwidth 
and  reliably  distribute  payment  to  the  nodes  that  provide  it.  The  system  must  be 
resilient  to  adversaries  attempting  to  identify  clients  or  fake  bandwidth  transfer. 

Preserving  Anonymity:  Among  Tor’s  existing  properties  that  TorCoin  must 
preserve,  no  Tor  client  can  recognize  another,  and  no  relay  can  identify  the  source 
and  destination  of  any  packet  flow.  Proposed  incentive  schemes  like  Tortoise  [5] 
and  Gold  Star  [3]  may  compromise  clients’  anonymity  by  allowing  their  traffic  to 
be  identified  [6].  In  a  proportionally  differentiated  service  [10,11]  like  LIRA  [6], 
a  speed-monitoring  adversary  can  potentially  partition  the  anonymity  set  into 
clients  that  are  paying  for  higher  speeds,  thus  reducing  anonymity.  TorCoin 
should  at  least  preserve  the  anonymity  of  the  current  Tor  protocol,  and  ideally 
improve  on  it  by  attracting  more  clients  and  relays. 

Verifiable  Bandwidth  Accounting:  TorCoin  needs  to  measure  bandwidth  in 
such  a  way  that  anyone  can  verify  its  measurements.  Optimally,  it  will  not  require 
self-reporting  or  centralized  servers,  unlike  EigenSpeed  [12]  or  Opportunistic 
Bandwidth  Monitoring  [13].  The  system  should  be  robust  to  attackers  or  groups 
of  attackers  colluding  to  misreport  bandwidth  measurements,  and  the  entire 
network  should  agree  on  all  measurements.  Rather  than  relying  on  reported 
network  speeds,  TorCoin  uses  an  onion-hashing  scheme  to  push  bandwidth  probe 
packets  through  Tor  circuits  to  measure  their  end-to-end  throughput. 

Anonymous  Payment  Distribution:  Once  TorCoin  measures  the  bandwidth 
a  given  relay  has  contributed  to  the  Tor  network,  TorCoin  must  distribute  pay¬ 
ment  to  that  relay  in  a  way  that  preserves  anonymity.  Specifically,  no  one  should 
be  able  to  associate  a  bandwidth  payment  or  measurement  with  a  specific  relay. 
Since  TorCoin  also  requires  verifiable  accounting,  the  problem  becomes  how  to 
verify  bandwidth  without  identifying  its  provider. 

Reliable  Transaction  Storage:  TorCoin  must  store  sufficient  records  of  previ¬ 
ous  payments  to  avoid  rewarding  a  relay  twice  for  the  same  bandwidth  transfer. 
Prior  incentive  schemes  like  LIRA  [6]  use  a  trusted  central  bank  to  assign  coins 
and  track  spending,  making  the  incentive  scheme  dependent  on  the  central  au¬ 
thority.  TorCoin  avoids  relying  on  a  central  authority  by  using  the  Bitcoin  pro¬ 
tocol’s  distributed  ledger  to  track  transactions  and  avoid  double  spending  [14]. 

Incremental  Deployment:  To  simplify  deployability,  TorCoin  should  require 
minimal  changes  to  the  Tor  codebase,  and  should  not  significantly  increase  la¬ 
tency  of  requests.  A  good  incentive  scheme  should  also  be  scalable  to  accommo- 


Fig.  1.  High  level  TorCoin  system  architecture  for  clients  and  relays.  A  TorPath  Client 
assigns  Tor  circuits  to  chents  via  the  TorPath  protocol,  described  in  the  next  section.  A 
TorCoin  Miner  mines  TorCoins  and  stores  them  in  a  TorCoin  Wallet.  Each  Tor  Client 
and  Tor  Relay  operates  as  usual,  but  on  circuits  assigned  via  the  TorPath  protocol. 


date  a  large  number  of  users  and  relays  operating  concurrently.  TorCoin  pursues 
deployability  and  scalability  through  its  decentralized  structure  and  small  trans¬ 
action  overheads  supported  by  existing  technologies  such  as  Bitcoin. 

2.2  Key  Technical  Challenges 

To  illustrate  the  key  challenge  this  paper  addresses,  we  envision  a  naive  bandwidth- 
measurement  scheme  using  blinded  cryptographic  tokens  to  signify  bandwidth 
transfer.  Suppose  in  this  scheme,  a  client  is  able  to  give  erich  relay  a  token  for  a 
given  amount  of  bandwidth  the  relay  provides.  Relays  are  then  able  to  convert 
these  client-signed  tokens  into  some  form  of  currency.  Such  a  scheme  would  be 
vulnerable  to  colluding  groups  of  clients  rmd  relays,  however,  who  can  simply 
sign  each  other’s  transfer  tokens  without  actually  transferring  any  bandwidth. 

We  address  this  challenge  via  the  TorPath  scheme  described  below.  TorPath 
restricts  clients’  ability  to  choose  their  own  path,  ensuring  that  most  paths  in¬ 
clude  at  least  one  non-colluding  participant  (the  client  or  at  least  one  of  the 
three  relays).  Assignment  servers  bundle  large  groups  of  clients  and  relays  into 
groups  that  collectively  choose  paths.  Even  in  the  relatively  rare  event  that  a 
path  constructed  this  way  consists  entirely  of  colluding  clients  and  relays,  an 
upper  bound  on  the  number  of  coins  each  path  can  mint  rate-limits  potential 
loss  to  these  few,  probabilistically  rare,  entirely-colluding  paths. 


3  TorCoin  Architecture 


The  TorCoin  architecture  consists  of  two  protocols,  TorCoin  and  TorPath.  In 
brief,  the  TorCoin  protocol  is  a  Bitcoin  variant  that  mines  coins,  while  TorPath 
protocol  assigns  a  circuit  (entry,  middle,  and  exit  servers)  to  each  client,  thereby 
“authorizing”  the  minting  of  TorCoins  through  verifiable  proof-of-bandwidth. 

TorCoin  runs  as  a  standalone  service,  requiring  little  modification  to  the 
Tor  or  Bitcoin  codebase.  Tor  clients  and  relays  operate  as  usual,  except  clients 
receive  circuit  assignments  from  assignment  servers,  instead  of  choosing  relays 
arbitrarily  from  the  Tor  directory.  Separately,  a  TorCoin  Miner  on  each  machine 
mines  TorCoins  by  monitoring  the  throughput  of  the  local  Tor  TLS  tunnel,  and 
communicating  with  its  circuit  neighbors  via  the  TorCoin  algorithm. 

Figure  1  shows  a  basic  overview  of  this  architecture. 

3.1  Adversary  Model 

We  are  primarily  concerned  here  with  an  adversary  who  wishes  to  obtain  Tor- 
Coins  without  contributing  useful  bandwidth  to  the  Tor  network.  We  assume 
the  adversary  is  able  to  control  a  number  of  clients  and  relays.  We  assume  that 
malicious  clients  and  relays  know  about  each  other  and  are  able  to  collude.  We 
also  assume  that  the  adversary  is  able  to  control  a  minority  of  assignment  servers 
on  the  network,  and  that  other  servers  are  honest-but-curious. 

3.2  The  TorPath  Protocol 

The  TorPath  protocol  assigns  Tor  circuits  to  clients,  replacing  the  usual  Tor 
directory  servers  with  assignment  servers,  which  form  decentralized  consensus 
groups.  The  protocol  guarantees  that  no  participant  on  a  circuit  can  identify  all 
other  participants,  and  that  each  circuit  includes  a  publicly  verifiable  signature. 
We  use  TorPath  to  “sign”  each  TorCoin,  so  that  anyone  can  verify  a  TorCoin’s 
validity  by  comparing  its  signature  to  a  global  history  of  consensus  groups. 

Requirements:  The  TorPath  protocol  adheres  to  the  following  constraints: 

~  No  client  can  generate  its  own  circuit. 

—  Every  circuit  has  a  unique,  publicly-verifiable  signature. 

—  No  client  can  know  the  circuit  of  another  client. 

Protocol  Outline:  The  TorPath  protocol  consists  of  three  sequential  steps: 

1.  Group  Initialization.  Assignment  servers  form  a  consensus  group.  Clients 
and  available  relays  provide  public  keys  to  join  the  group. 

2.  Verifiable  Shuffle.  The  consensus  group  performs  a  decentralized,  verifiable 
shuffle  of  all  the  public  keys,  resulting  in  a  circuit  assignment  for  each  client. 

3.  Path  Lookup.  The  assignment  servers  publish  the  result  of  the  shuffle,  such 
that  each  client  can  identify  only  its  entry  relay,  and  each  relay  can  identify 
only  its  immediate  neighbor (s)  in  the  circuit. 


(a)  (b) 


Fig.  2.  Both  relays  and  clients  use  onion-encryption  to  encrypt  their  own  temporary 
public  keys  with  the  public  keys  of  all  the  assignment  servers  in  the  group,  (a)  Each 
client  generates  one  keypair,  and  sends  its  public  key  onion- encrypted  to  the  server, 
(b)  Each  relay  generates  multiple  keypairs,  to  support  multiple  clients  and/or  circuit 
positions  within  a  consensus  group,  as  instructed  by  the  assignment  servers. 


Stage  1  —  Group  Initialization:  A  consensus  group  is  formed  when  a  suitable 
quorum  of  assignment  servers  come  together  to  eissign  circuits  to  recently  regis¬ 
tered  clients.  For  example,  if  there  are  10  assignment  servers  in  the  network,  we 
might  require  at  least  6  of  them  to  participate  in  forming  eeich  consensus  group. 
The  assignment  servers  can  modulate  the  size  -  and  hence  anonymity  -  repre¬ 
sented  by  each  consensus  group,  by  waiting  until  there  are  some  configurable 
number  n  of  clients  registered  before  proceeding  to  the  next  stage.  Different  cat¬ 
egories  of  consensus  groups  might  use  different  values  of  n,  aillowing  clients  to 
trade  anonymity  for  wait  time.  Groups  with  leirger  values  of  n  would  provide  a 
larger  anonymity  set,  at  the  expense  of  longer  circuit  setup  times. 

A  consensus  group  forms  in  three  steps: 

1.  Each  assignment  server  shares  its  public  key  with  its  group  members, 
and  broadc£ists  these  public  keys  to  all  clients  and  relays  connected  to  it. 

2.  Each  client  connects  to  one  assignment  server  in  the  group.  The  client  then 
generates  a  temporary  private  and  public  key  pair.  The  client  onion-encrypts 
its  temporary  public  key  with  the  public  keys  of  all  assignment  servers  in  the 
group,  resulting  in  a  ciphertext  that  each  server  can  only  partially  decrypt. 
The  client  submits  this  ciphertext  to  its  assignment  server. 

3.  Each  relay  can  act  as  an  entry,  middle,  and/or  exit  relay,  and  it  chooses 
which  pcisition(s)  to  service.  The  number  of  available  relays  available  for  a 
given  position  (especially  exit  relays)  may  often  be  less  than  the  number 
of  clients  in  the  group  needing  circuits.  To  ensure  parity  between  chents 
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Fig.  3.  Example  matrix  shuffle  with  5  clients  (Ci,  C^,  C3,  C4  and  Cs)  and  4  relays 
(purple,  blue,  green,  red).  Each  relay  Rt  generates  a  number  of  public  keys  Kp  for  each 
circuit  position  p  e  E,M,X,  as  instructed  by  its  assignment  server.  Here,  each  chent 
Cj  is  assigned  the  circuit  represented  by  the  j**  row  of  the  shuffled  matrix. 


tind  relays  for  each  position,  each  assignment  server  instructs  its  relays  to 
generate  a  sufficient  number  of  temporary  keys  for  each  position.  The  relay 
server  uses  onion-encryption  to  generate  n  ciphertexts  from  n  temporary 
pubhc  keys.  The  relay  packages  these  ciphertexts  by  position  and  sends  them 
to  its  upstream  assigmnent  server. 

Figure  2  illustrates  Steps  2  and  3. 

We  can  represent  the  temporary  keys  as  an  n  x  4  matrix  M  for  n  chents, 
where  each  row  corresponds  to  a  client  and  its  three  relays  (see  Figure  3). 

Stage  2  —  Verifiable  Shuffle:  The  consensus  group  now  shuffles  each  column 
of  the  temporary  key  matrix  independently,  using  a  verifiable  shuffling  algorithm 
such  as  the  Neff  Shuffle  [15]),  and  jointly  decrypts  the  shuffled  keys.  Each  row 
in  the  public  result  matrix  now  contains  a  random  4-tuple  of  temporary  pubhc 
keys  representing  one  circuit:  namely  the  client  and  the  three  relays  serving  that 
client.  The  assignment  servers  collectively  sign  and  publish  the  resulting  matrix 
to  a  public  log,  accessible  by  all  clients  and  relays.  Although  everyone  learns 
which  four  temporary  public  keys  represent  the  participants  of  each  circuit,  the 
verifiable  shuffle  prevents  anyone  except  a  given  key’s  owner  from  learning  which 
participating  client  or  relay  owns  each  of  these  temporary  keys. 


Sender 

Message  Tuple 

Client 

[Kh,  {IPh}K^J 

Entry  relay 

(Ak,  {IPh}Ki,, 

Middle  relay 

{Kit,  {IPm]k^^) 

Exit  relay 

{Kit,  {IPk}K-J 

Table  1.  Each  participant  in  a  circuit  sends  its  message  tuple  onion-encrypted  to  the 
server.  {X}y  denotes  X  encrypted  with  Y. 


Stage  3  —  Path  Lookup:  In  the  final  step  of  the  algorithm,  each  client  obtains 
the  IP  address  of  its  entry  relay,  and  each  relay  obtains  the  IP  address  of  its 
neighbor(s)  on  the  circuit.  The  path  lookup  algorithm  ensures  that  each  client 
and  relay  can  obtain  only  the  IP  addresses  of  its  neighbors  in  the  circuit. 

Each  client  encrypts  its  own  IP  using  the  public  key  of  its  neighbor.  The 
client  forms  a  tuple  (public  key,  encrypted  IP)  as  shown  in  table  1.  The  client 
onion-encrypts  this  tuple  and  sends  it  to  the  assignment  servers.  Each  relay 
follows  the  same  procedure,  for  every  key  in  the  matrix  belonging  to  it. 

The  assignment  servers  shuffle  this  new  list  of  tuples.  Each  client  and  relay 
now  finds  its  neighbors  in  the  matrix  by  locating  the  tuples  containing  the  public 
keys  it  needs.  Finally,  each  participant  decrypts  the  relevant  cells  using  its  private 
key,  revealing  the  IP  address  of  its  circuit  neighbor(s). 

Now  all  clients  in  the  consensus  group  have  a  usable  Tor  circuit. 

Each  circuit  formed  by  a  consensus  group  obtains  a  unique  Circuit  Identifier, 
which  is  an  ordered  pair  consisting  of  the  hash  of  the  matrix  M  and  the  row 
number  i  of  the  circuit  within  M:  CSi  =  (Hash(M),i).  This  identifier  will  be 
used  in  the  TorCoin  algorithm,  together  with  signatures  using  the  four  anony¬ 
mous  temporary  public  keys  comprising  that  row  of  M,  to  prove  that  TorCoins 
were  minted  by  circuits  assigned  in  consensus  groups. 

Security  Considerations 

Anonymity:  The  TorPath  protocol  guarantees  that  no  single  relay  knows  any 
client’s  entire  circuit.  If  malicious  clients  or  relays  collude,  they  may  be  able  to 
shrink  the  anonymity  set  to  the  set  of  honest  relays  and  clients  in  the  consensus 
group.  Groups  can  have  varying  sizes,  however,  allowing  clients  to  choose  a 
desired  balance  between  anonymity  threshold  and  circuit  assignment  delay. 

Group  Formation:  The  TorPath  protocol’s  random  circuit  selection  mecha¬ 
nism  prevents  colluding  clients  and  relays  from  deterministically  placing  them¬ 
selves  in  the  same  circuit,  provided  not  too  many  participants  in  each  group 
collude.  Even  if  half  of  the  temporary  keys  in  matrix  M  are  held  by  colluding 


participants,  for  example,  only  1/2^  =  1/16  of  the  assigned  circuits  will  be  com¬ 
promised  and  able  to  mint  (a  limited  number  of)  TorCoins  without  performing 
useful  work.  We  could  add  further  protection  against  “flash  mobs”  of  collud¬ 
ing  participants  by  randomizing  group  assignment  across  longer  time  periods, 
instead  of  using  temporal  locality  as  the  only  grouping  criterion. 

Circuit  Diversity:  TorCoin’s  Neff  shuffle  could  assign  the  same  relay  to  one 
circuit  in  multiple  positions:  e.g.,  choose  the  same  physical  relay  as  both  entry 
and  middle  relays.  With  a  reasonable  number  of  participating  relays,  however, 
it  should  be  extremely  unlikely  that  one  relay  gets  assigned  to  all  three  positions 
on  the  same  circuit.  In  any  case,  the  risk  of  accidental  relay  duplication  on  one 
path  should  not  be  substantially  greater  than  the  risk  Tor  users  already  face  of 
randomly  placing  multiple  relays  owned  by  the  same  operator  on  a  circuit.  We 
anticipate  that  privacy-preserving  independence  testing  techniques  [16]  could 
be  adapted  to  detect  and  reject  circuits  in  which  the  same  relay  (or  operator) 
appears  multiple  times,  but  we  leave  this  challenge  to  future  work. 

Persistent  Guards:  The  assignment  process  above  picks  three  relays  afresh 
for  each  circuit,  contrary  to  Tor’s  practice  of  keeping  entry  relays  persistent  for 
longer  periods.  The  circuit  assignment  mechanism  could  be  adapted  for  per¬ 
sistent  entry  relays  by  combining  the  first  two  columns  of  matrix  M  into  one 
column  representing  each  client  together  with  its  choice  of  entry  relay,  at  the 
cost  of  slightly  increasing  the  chance  of  forming  all-compromised  circuits. 

3.3  TorCoin  Mining 

In  contrast  with  Bitcoin’s  reliance  on  proof  of  computation,  mining  TorCoin 
requires  proof  of  Tor  bandwidth  transfer.  In  TorCoin,  all  participants  on  a  cir¬ 
cuit  assigned  by  TorPath  may  collectively  mine  a  limited  number  of  TorCoins, 
incrementally,  based  on  the  end-to-end  goodput  they  observe  on  the  circuit. 

Proof  of  Bandwidth 

1.  Each  client  and  relay  creates  a  temporary  key  R  and  its  hash  =  Hash(i?*). 

2.  Every  m  Tor  packets,  the  client  sends  a  tuple  (coin#,!?/,),  where  coin#  is 
the  number  of  TorCoin  packets  previously  sent  in  this  circuit. 

3.  Each  relay  similarly  adds  its  own  temporary  hash  to  the  tuple  -  R'^, 
and  R'^  -  and  forwards  the  tuple  to  the  next  relay  in  the  circuit. 

4.  The  exit  relay  forms  the  coin  commitment  blob  B  —  (coin#,  i?/.,  R'^,  R'^,  R'x)- 

5.  The  exit  relay  then  signs  the  blob  B  with  its  temporary  public  key  for  this 
circuit  to  create  signature  ,  then  opens  its  commitment  to  reveal  Rx ,  and 
sends  the  tuple  (B,  S'^,  Rx)  to  the  middle  relay. 

6.  Each  prior  participant  in  the  circuit  i,  in  turn,  similarly  signs  the  blob  B 
to  create  Sf  ^  adds  its  signature  and  opened  commitment  to  the  tuple,  then 
forwards  the  tuple  to  the  previous  participant  in  the  circuit. 

7.  The  client  forms  bandwidth  proof  P  =  (B,  Sx,S^,  S§,Sq,  Rx,Rm,  Re,  Rc), 
which  anyone  may  verify  against  the  four  temporary  public  keys  in  the  ap¬ 
propriate  row  of  matrix  M  for  this  circuit. 


Fig.  4.  TorCoin  Proof  of  Bandwidth  algorithm.  In  the  upper  part  of  the  cycle,  the 
relays  add  their  hashes  to  the  tuple.  In  the  lower  part,  they  add  their  temporary  keys 
and  sign  the  tuples. 


8.  To  check  if  a  TorCoin  has  been  mined,  the  client  checks  if  the  lower-order 

bits  of  Hash(C5i,B,  ==  0-  If  so,  the  client  adds  the  full 

proof-of-bandwidth  tuple  P  to  the  blockchain  to  validate  the  new  TorCoin. 
To  be  valid,  the  coin#  within  P  must  be  one  greater  than  that  of  the  last 
TorCoin  in  the  blockchain  mined  from  circuit  i,  and  must  be  less  than  the 
well-known  limit  on  the  number  of  TorCoins  per  assigned  circuit. 

9.  Finally,  the  client  uses  the  standard  Bitcoin  transfer  protocol  to  pay  each 
relay  in  the  circuit  one  third  of  the  mined  TorCoin. 

This  protocol  leaves  all  information  necessary  for  verifying  proof-of-bandwidth 
in  the  blockchain.  Any  interested  party  can  verify  that  the  circuit  identifier  in 
B  refers  to  a  valid  consensus  group  by  referring  to  the  public  log.  They  can  also 
verify  that  the  blob  B  was  signed  by  the  correct  participants  by  verifying  the 
signatures  against  the  temporary  public  in  the  consensus  matrix  M,  and  verify 
that  the  openings  Ri  correspond  to  the  corresponding  commitments  R[ .  Because 
the  low-order-bit  test  in  step  8  depends  only  on  values  secretly  committed  on  the 
“forward  path”  in  steps  2^,  then  revealed  only  on  the  “return  path”  in  steps 
5-6,  no  proper  subset  of  the  circuit’s  participants  can  unilaterally  recompute  B 
in  order  to  mine  TorCoins  out  of  proportion  to  measured  circuit  goodput. 

Security  Considerations 

Enforcing  packet  rate:  All  honest  relays  and  clients  enforce  the  standard 
TorCoin  packet  rate  m.  Any  relays  or  clients  that  deviate  from  this  are  reported 
to  the  assignment  servers  rmd  the  circuit  is  terminated. 


Enforcing  circuits:  Relays  know  their  neighbours’  IP  addresses  and  will  refuse 
connections  from  any  other  IP  address.  Even  if  malicious  relays  connect  to  each 
other,  they  will  not  be  able  to  sign  TorCoins  unless  they  own  a  complete  circuit. 

Compromised  circuits:  Colluding  clients  and  attackers  needs  to  control  all 
four  components  of  a  circuit  to  mine  TorCoins  fraudulently.  Even  if  an  adversary 
controls  up  to  half  the  network,  only  1/2"^  =  1/16  of  assigned  circuits  will  be 
fully  colluding.  In  practice,  we  hope  and  expect  that  gaining  control  of  even  half 
of  all  Tor  clients  and  relays  would  be  difficult.  To  limit  the  impact  of  occasional 
colluding  circuits,  TorCoin  also  limits  the  number  of  coins  each  circuit  can  mine. 
This  coin  number  is  included  in  the  blockchain,  so  it  is  easily  verified.  The  im¬ 
pact  of  compromised  circuits  can  be  further  reduced  by  ensuring  that  consensus 
groups  expire  at  regular  intervals,  requiring  clients  either  to  form  new  circuits 
or  cease  obtaining  new  TorCoins  from  old  circuits. 

Bitcoin  anonymity:  This  paper  focuses  on  adapting  Bitcoin’s  mining  scheme 
to  measure  Tor  bandwidth  instead  of  computation,  and  not  on  Bitcoin’s  trans¬ 
action  mechanism.  Since  TorCoin  also  needs  to  protect  the  anonymity  of  clients 
as  they  make  transactions,  we  must  also  account  for  well-known  concerns  about 
the  limited  anonymity  the  basic  Bitcoin  transaction  protocol  offers  [17].  Any  of 
the  recently  proposed  approaches  such  as  Zerocoin  [18],  Mixcoin  [19],  or  Coin- 
Shuffle  [20]  should  offer  a  suitable  solution  to  this  orthogonal  challenge. 

Deployment:  The  TorPath  network  is  not  backward  compatible  with  the  ex¬ 
isting  Tor  network,  due  to  the  fundamental  differences  of  route  assignment  and 
access  control,  which  are  missing  in  Tor  but  necessary  for  the  TorPath  and  Tor- 
Coin  schemes  to  work.  However,  any  given  physical  server  could  run  both  services 
at  the  same  time.  TorCoins  are,  of  course,  generated  only  from  TorCoin  traffic. 

4  Preliminary  Results 

The  TorCoin  protocol  adds  a  small  amount  of  overhead  to  Tor  traffic.  To 
evaluate  this  overhead,  we  set  up  a  series  of  servers  using  the  Python  Twisted 
framework  [21]  to  simulate  the  passing  of  TorCoin  generation  and  verification 
messages  through  a  set  of  relays. 

Assuming  that  the  keys,  hashes  and  signatures  are  all  32  bytes  in  length, 
the  total  overhead  from  one  round  of  successful  TorCoin  mining  (i.e.,  one  entire 
round  trip  from  client  through  all  the  relays  and  back  again)  results  in  a  total 
TorCoin  packet  overhead  of  1752  bytes.  This  can  be  broken  down  into: 

—  The  first  packet  from  client  to  entry  relay:  34  bytes. 

—  Packet  forwarded  from  entry  to  middle  relay:  66  bytes. 

—  Packet  forwarded  from  middle  to  exit  relay:  98  bytes. 

—  Packet  from  from  exit  to  middle  relay:  324  bytes. 

—  Packet  from  from  middle  to  entry  relay:  518  bytes. 

—  Packet  from  from  entry  relay  to  client:  712  bytes 

—  Total:  1752  bytes 
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Fig.  5.  TorCoin  packet  overhead 


Each  round  of  TorCoin  generation  and  verification  happens  only  after  m  Tor 
packets  have  been  sent.  Each  standard  Tor  cell  is  514  bytes  long,  so  each  round 
trip  on  the  network  requires  transmission  of  514  *  6  =  3084  bytes.  Thus,  if 
m  >  10,  the  TorCoin  protocol  overhead  is  around  5%.  The  value  of  m  can  be 
calibrated  in  further  experimentation  and  as  needed  in  order  to  achieve  the  sweet- 
spot  of  transmission  efficiency  and  incentive  maximization  for  relay  providers. 

The  system  might  decrease  the  value  of  m  when  load  is  high,  incentivizing 
relay  operators  to  provision  more  relay  bandwidth  at  such  times. 

While  the  Neff  shuffle  is  complex  and  requires  several  communications  be¬ 
tween  the  servers,  we  expect  the  eissignment  servers  will  be  few  (less  than  10) 
2md  well-provisioned,  and  do  not  expect  the  shuffles  to  be  a  major  bottleneck. 
Since  this  is  a  one-time  cost  of  cormecting  to  the  network,  we  hope  users  will 
Eiccept  this  setup  time  if  it  gives  them  access  to  higher-capacity  relays.  For  impa¬ 
tient  users,  the  TorCoin  client  could  use  conventional  Tor  circuits  immediately 
on  startup,  then  transition  to  TorCoin  circuits  as  they  become  available. 


5  Conclusions 

We  have  introduced  TorPath,  a  novel  scheme  to  assign  paths  to  Tor  chents 
securely  and  anonymously.  TorPath  motivated  by  the  need  to  verifiably  mine 
TorCoins,  a  a  Bitcoin  variant  based  on  measured  bandwidth  over  the  Tor  net¬ 
work.  The  TorCoin  protocol  is  robust  to  malicious  relays  and  clients  colluding 
to  mint  TorCoins  without  transferring  bandwidth. 
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